前面說了許多關於程式碼相關的規範，其實在團隊協作中也有許多要注意的地方，像是 git commit message、PR 的發送方式等等。

git branch

我們採用 gitflow 的方式進行開發，開發時一律從 develop 分支出 feature branch，開發完成後發送 feature -> develop 的 PR，注意這邊不是到 master，因為我們的 master 會自動部署到正式站，所以 PR 才是合併到 develop，接著需要手動將 release branch rebase 到最新的 develop 上面，因為我們的測試站是跟著 release branch 走的，如此一來我們的 QA/QC 才可以進行測試。一般來說我們是每天下班前會將 release branch 進行一次 rebase。

• 共用分支
  • master 正式站自動部署綁定的分支
  • release 測試站自動部署綁定的分支
  • develop 共用的開發分支
• Branch 規範
  release 附屬於 master、feature 附屬於 develop，所以 master 和 develop 不能 rebase + force push，不然其他人的本地端開發中的 branch 處理起來會很麻煩。

  要改動系統時盡量開分支去做

  • 常用分類
    • feature/
    • bugfix/
    • refactor/
    • hotfix/
  • 分支名稱採 dash-case
    • feature/new-feature
    • bugfix/fix-some-bugs

git commit message

主要參照 google 的 commit message guide

• Commit 規範
  • 全英文，用一句話簡述這個 commit 做了什麼，盡量寫人話而非工程用語
  • 一個 commit 只做一件事，如果發現句子裡有很多「and」或是「頓號」代表這個 commit 可能做了太多事情，盡量拆成較為輕量的 commit
  • 標籤類型
    • [FEATURE] build new features
    • [BUGFIX] fix some bugs
    • [STYLE] format codes of rename files
    • [REFACTOR] rewrite dirty codes
    • [UPDATE] update dependencies

pull request

由於常常會遇到 PR 發了被堆很久，或者是 PR 過於肥大的問題，於是我們建立了以下規範：

• 實作時，可先做好一小部分原型先發 PR 供檢視是否符合要求並另開分支繼續作業
• 發 PR 時註記從哪一個檔案開始看，可以提昇 reviewer 的觀看效率
• 發出 PR 三天後無人 review 則須主動找人幫你 review
• 除非這個 branch 有相依的 branch，例如Ｂ功能要等Ａ功能先完成，則Ｂ的 PR 選擇合併到Ａ，否則以 develop 為主
• 所有人都可以對自己或別人的 PR 留下評論，盡量用英文
• 可以搭配一些程式碼片段或參考資料的連結作為輔助
• 請試著為自己辯護，問問自己當初為什麼這樣寫，比較不同寫法的優劣
• 檢查要點：
  1. 一定要可以編譯執行
  2. 是否有完成需求
  3. 程式碼可讀性
  4. 架構擴充性
• NITS 代表雖然不影響功能，但可以試著修改成比較好的寫法
• 審核通過後由專案負責人合併進 develop，已經被合併的 branch 就可以刪除了
• 合併進 develop 者同時需將其合併至 release branch ，使其可供測試